With continuous expansion of a network scale, a traffic engineering technology emerges. A main objective of traffic engineering is to maximize utilization of network resources and improve network performance while ensuring efficiency and reliability of a network operation. Operation costs and expenses of an entire network are reduced by using a bandwidth resource more efficiently. A phenomenon that some links are congested while some links are idle is avoided by allocating traffic properly. Optimization of network resource utilization is implemented and overall performance of a network is improved by planning the traffic properly. In addition to a distributed computation method, such as a Multiprotocol Label Switching-Traffic Engineering (MPLS-TE) technology that is used to compute a path, a centralized path computation architecture may also be used to compute a path.
As shown in FIG. 1, a centralized path computation system includes two main components: a path computation client (PCC) and a path computation element (PCE). Message interaction is performed between the path computation client and the path computation element by using a Path Computation Element Communication Protocol (PCEP). Specifically, the path computation element may further include a traffic engineering database and a policy module. The traffic engineering database includes information such as a topology of a network, link bandwidth, a delay, and a packet loss. The policy module can configure a path computation policy.
As shown in FIG. 2, if a path computation client wants to perform path computation, the path computation client sends a path computation request PCReq message to a path computation element, where the message includes information such as source and destination identifiers of a path and required bandwidth. After receiving the PCReq message, the path computation element computes a path according to a requirement in the message. If a path meeting the requirement is found by means of computation, a path computation response PCRep success message is returned; or if the path meeting the requirement cannot be found, a PCRep failure message is returned.
Because path flapping may exist (for example, a device on the path fails), after receiving the successful path information, the path computation client needs to know whether the path is still normal. As shown in FIG. 3, after receiving a successful PCRep message, the path computation client starts a timer. Once the timer expires, the path computation client sends a PCReq path recomputation message to the path computation element, where the message carries original path information. After receiving the PCReq message, the path computation element performs the path computation again. In this way, the path computation client can know whether the path is still normal.
However, in actual application, timed recomputation only adapts to a scenario in which only bandwidth is considered, such as a scenario in which bandwidth is reserved based on a Resource ReSerVation Protocol (RSVP). In some other scenarios in which not only bandwidth is considered, but also network performance parameters such as a packet loss, a delay, and jitter need to be considered, for example, in an intelligent routing network system, parameters such as a packet loss and a delay dynamically change in a network. If an expiration time of a recomputation timer of the path computation client is set to be extremely long, changes of the packet loss and the delay may be missed, and consequently a path cannot be adjusted in a timely manner; if the expiration time of the timer is set to be extremely short, a quantity of communication messages between the path computation client and the path computation element is increased, and communication burden of the path computation client and the path computation element is increased.